This PR fixes the following bit representation derivation issues:

1. Quadratic compilation time when deriving

The process of deriving DataReprAnn has quadratic complexity in the size of constructors and fields.

For example this data type:

data ManyCons
   = ManyCons1  (Index 10) (Index 11) (Index 12)
   | ManyCons2  (Index 11) (Index 12) (Index 13)
   | ManyCons3  (Index 12) (Index 13) (Index 14)
   | ManyCons4  (Index 13) (Index 14) (Index 15)
   | ManyCons5  (Index 14) (Index 15) (Index 16)
   | ManyCons6  (Index 15) (Index 16) (Index 17)
   | ManyCons7  (Index 16) (Index 17) (Index 18)
    
$(deriveAnnotation (simpleDerivator OneHot OverlapR) [t| ManyCons |])
$(deriveBitPack [t| ManyCons |])

Going from 1 constructor to all 7 yields these compilation times on my machine:

• 1 constructors: 4.84 seconds
• 2 constructors: 3.31 seconds
• 3 constructors: 4.43 seconds
• 4 constructors: 7.31 seconds
• 5 constructors: 12.06 seconds
• 6 constructors: 23.03 seconds
• 7 constructors: 47.78 seconds

The reason is that the TemplateHaskell in deriveAnnotation creates insanely large annotations. See this file where I dumbed the splice(-ddump-splices) for the case with 4 constructors.

This PR fixes this issue by introducing let-bindings of commonly used sub-expressions in the generated annotation. See here for the generated annotation after this PR.

A quick test shows these compilation times after this PR:

• 1 constructors: 2.55 seconds
• 2 constructors: 2.61 seconds
• 3 constructors: 2.67 seconds
• 4 constructors: 2.87 seconds
• 5 constructors: 3.11 seconds
• 6 constructors: 2.85 seconds
• 7 constructors: 2.92 seconds
• 32 constructors: 5.03 seconds

2. Promoted data cons and symbols

Promoted data cons and symbols weren't supported at all. Which lead to issues were you used promoted data constructed as a parameter to a type you wanted to derive a bitrepresentation for. Or if you wanted to for example use the domain somewhere in your data type.

3. Type synonyms weren't resolved

During the process of finding types annotation exist for there could be a mismatch because the types coming via GHC core had their type synonyms resolved. While the types coming in via the annotation hadn't. The result was that if you use a type synonym somewhere in the annotation it wouldn't be able to match it with any type in the Custom representation map. Now it always fully resolves that type during the Template Haskell phase at the annotation.